Logic Analyzers are tools that capture the (binary) logic values of TRUE and FALSE for signals that occur during the operation of digital equipment. As inputs to the Logic Analyzer, these signals are individually referred to as channels and are often grouped into related named collections, such as signals defining a bus within the digital equipment under test. The related signals might have a collective meaning, such as a value for data, an address, or simply represent some other internal condition that is quite particular to the operation of the digital equipment, or of some other apparatus. The ‘meaning’ is generally called a ‘state’ (as in ‘state of affairs’—or ‘condition’) and its value may be indicated through the use of some convenient integer notation, such as binary or hexadecimal. In any event, Logic Analyzers (sometimes called Logic State Analyzers, or just State Analyzers) usually capture entire sequences of such states and store their descriptions in a memory. The stored information is called a ‘trace’ and can be inspected to help verify proper system operation or diagnose problems.
The vast majority of signals measured by Logic Analyzers are clocked signals, meaning that changes in states are synchronous with transitions in an associated clock signal. The transitions in the clock signal indicate when the logic values of the data signals are to be measured, or captured. This leads us to observe that Logic Analyzers make extensive use of threshold detection: (i) a transition through a threshold for a clock signal indicates a time when (ii) existing (earlier) threshold comparisons for data signals are to be captured as a state.
Threshold detection is performed by placing a voltage comparator circuit in the path of every signal of interest. That is, every channel, whether for a data signal or a clock, is equipped with a comparator. A comparator is a two-input circuit. One input is the signal of interest (the input to the channel) and the other is a selectable comparison voltage commonly called a threshold. The function of the comparator is to indicate at an output whether the signal input for the channel is above or below the threshold. Using signaling voltages having levels convenient for the internal operation of the Logic Analyzer, the comparator will output a logic ONE or TRUE if the input voltage meets or exceeds the threshold voltage, and will output a logic ZERO or FALSE if the input is less than the threshold. (Of course, the ‘meets’ or ‘equals’ aspect of the threshold can be attached to either one—but not to both—of the ‘greater than’ and ‘less than’ conditions.) A hysteresis arrangement uses a small offset to produce slightly different ‘effective thresholds’ for different directions of input signal transition. This prevents indecision (instability) in the output should the input dwell on exactly the threshold, or exhibit noise centered about the threshold. Threshold detection by such comparators can be characterized as converting from whatever signal levels are used in the System Under Test (SUT) to the particular ones used internally by the Logic Analyzer. It is clear that correct operation of a Logic Analyzer depends upon proper threshold comparison. Attending to the selection of proper threshold voltages for the various input signals is one of the main things that the operator of a Logic Analyzer must do.
Logic Analyzers typically have controls that allow the selection of pre-set, or the manual adjustment of, channel thresholds. Sometimes channels are individually adjustable, while other times economic reasons cause related channels to share a common threshold voltage. For example, it is common for there to be ‘Probe Pods’ attached to the Logic Analyzer through umbilical cables having eight (or sixteen) data channels that share a common adjustable threshold. The designer's assumption is that all eight (or sixteen) SUT channels connected to a particular Probe Pod are likely to share a common logic family, and that a single threshold for all those signals is adequate. There might be a ninth (or seventeenth) channel having a separately adjustable threshold and that is intended for use with a clock signal associated with the data channels of that Probe Pod.
If a threshold is set correctly, it is near the middle of the signal swing for the signal it is to characterize. The usual way to pick the threshold is to consider two identical channels simultaneously undergoing transitions in opposite directions. At some point in time the two channels will exhibit the same voltage. It is this ‘crossover’ point which is the desired threshold voltage. This technique accounts for the fact that the transitions have finite rise and fall times (if the rise and fall times were actually zero, we would just pick as the threshold the midpoint between signal extremes, and be done with it . . . ), and is generally thought to give the most faithful translation of signal timing from the (external) SUT levels to the (internal) levels used within the Logic Analyzer.
As the threshold is set farther from the optimum (crossover) value described above, the timing of the translated signal becomes more and more distorted. Eventually, for a threshold set above or below the limits of the external (input) levels, the translated (internal) signal becomes a constant value of respective FALSE or TRUE, and all timing information (and information content!) from the external input signal is lost.
Thus, if the threshold for any input signal to the Logic Analyzer is set inappropriately (significantly away from the crossover value, or even near or outside the voltage limits of the signal swing), little or no useful information about the signal can be acquired. If that signal is used as a clock (or as a clock qualification component) in a synchronous acquisition (i.e., as part of a logic state measurement), then little or no information about ANY signal will be acquired. The extreme condition where the signal swing for a clock seldom or never crosses the threshold is variously known as an “idle clock input” or as a “slow or missing clock input”. The trace will be missing entire sections corresponding to where there ‘was no clock’, and sections that are present may be corrupt. If the signal with an inappropriate threshold is a data (non-clock) signal, then captured state data may be corrupted, with whatever attendant implications for the understanding of the trace. It is abundantly clear that successful operation of a Logic Analyzer depends upon proper settings for the thresholds.
Some prior art Logic Analyzer systems have implemented schemes for alerting the user that an input channel appears to be inactive. For example, U.S. Pat. No. 4,293,925 describes just such a system. For each channel that does not eventually exhibit a different logical value when sampled periodically, it displays an ‘idle channel’ indicator. More refined versions of this further indicate for each channel if the associated threshold is above, below or within the signal activity range for that channel. Such displays of information consume space on the display, and may be perceived as clutter when not needed. Such indications can either be (wrongly) ignored or turned off to simplify the presentation. Furthermore, other subsequent errors or abnormalities may be announced which are caused by an inappropriate threshold, but whose accompanying indicia or legends are more general and not specific to simply thresholds. So, for example, a Logic Analyzer whose clock threshold is too high will stall the entire measurement. The accompanying error message might be “WAITING FOR TRIGGER” or perhaps, if the analyzer appreciates which channels are being used as clocks, “IDLE CLOCK INPUT” . . . . In any case, the notion that the threshold might be too high is lost as being just one among other possibilities, such as a flying lead that has become disconnected from its correct terminal, or that has been accidently connected to, say, ground. The point is that there might be no explicit mention of the term ‘THRESHOLD’ in the warning or error message. Indeed, a data channel with an out-of-bounds threshold might generate NO warning at all, as this is not a fatal condition that would keep the analyzer from running. It is just that the trace would be wrong. The operator could spend a lot of time looking for a problem in his SUT that is really just an inappropriate threshold setting for a channel of the Logic Analyzer.
In summary, the various prior art signal activity schemes all require that the user take the time to inspect these indicators, that he or she has a background that allows an informative interpretation of what is indicated, and that they be a good sleuth, to boot.
A knowledgeable and experienced operator can use the prior art controls and indicators to set thresholds to values that make sense for the SUT, as well as appreciate the differences between a likely SUT failure, botched probe connections and inappropriate thresholds. Less seasoned operators can experience trouble and frustration, or worse, not even appreciate that there is a problem. What might happen, for example, if they do not appreciate, or have forgotten about, the common threshold for a Probe Pod?
It would be desirable if a Logic Analyzer automatically presented signal activity and threshold information in a more informative format, and which took into account various configuration information used or solicited during measurement setup activities.